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Abstract 

Proof-carrying code is a framework for the mechani- 
cal verification of safety properties of machine language 
programs, but the problem arises of quis custodiat ip- 
sos custodes — who will verify the verifier itself? Founda- 
tional proof-carrying code is verification from the small- 
est possible set of axioms, using the simplest possible ver- 
ifier and the smallest possible runtime system. I will de- 
scribe many of the mathematical and engineering prob- 
lems to be solved in the construction of a foundational 
proof-carrying code system. 

1 Introduction 

When you obtain a piece of software - a shrink- 
wrapped application, a browser plugin, an applet, an OS 
kernel extension - you might like to ascertain that it’s safe 
to execute: it accesses only its own memory and respects 
the private variables of the API to which it’s linked. In a 
Java system, for example, the byte -code verifier can make 
such a guarantee, but only if there’s no bug in the verifier 
itself, or in the just-in-time compiler, or the garbage col- 
lector, or other parts of the Java virtual machine (JVM). 

If a compiler can produce Typed Assembly Language 
(TAL) [14], then just by type-checking the low-level rep- 
resentation of the program we can guarantee safety - but 
only if there’s no bug in the typing rules, or in the type- 
checker, or in the assembler that translates TAL to ma- 
chine language. Fortunately, these components are signif- 
icantly smaller and simpler than a Java JIT and JVM. 

Proof-carryingcode (PCC) [15] constructs and verifies 
a mathematical proof about the machine-language pro- 
gram itself, and this guarantees safety - but only if there’s 
no bug in the verification-condition generator, or in the 
logical axioms, or the typing rules, or the proof-checker. 
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What is the minimum possible size of the components 
that must be trusted in a PCC system? This is like ask- 
ing, what is the minimum set of axioms necessary to 
prove a particular theorem? A foundational proof is one 
from just the foundations of mathematical logic, without 
additional axioms and assumptions; foundational proof- 
carrying code is PCC with trusted components an order 
of magnitude smaller than previous PCC systems. 

Conventional proof-carrying code. Necula [15] 
showed how to specify and verify safety properties of 
machine-language programs to ensure that an untrusted 
program does no harm - does not access unauthorized 
resources, read private data, or overwrite valuable data. 
The provider of a PCC program must provide both the 
executable code and a machine-checkable proof that 
this code does not violate the safety policy of the host 
computer. The host computer does not run the given code 
until it has verified the given proof that the code is safe. 

In most current approaches to PCC and TAL [15, 14], 
the machine-checkable proofs are written in a logic with 
a built-in understanding of a particular type system. More 
formally, type constructors appear as primitives of the 
logic and certain lemmas about these type constructors 
are built into the verification system. The semantics of 
the type constructors and the validity of the lemmas con- 
cerning them are proved rigorously but without mechnical 
verification by the designers of the PCC verification sys- 
tem. We will call this type-specialized PCC. 

A PCC system must understand not only the language 
of types, but also the machine language for a particular 
machine. Necula’s PCC systems [15, 7] use a verification- 
condition generator (VCgen) to derive, for each program, 
a verification condition - a logical formula that if true 
guarantees the safety of the program. The code producer 
must prove, and the code consumer must check the proof 
of, the verification condition. (Both producer and con- 
sumer independently run the VCgen to derive the right 
formula for the given program.) 

The VCgen is a fairly large program (23,000 lines of C 
in the Cedilla Systems implementation [7]) that examines 




the machine instructions of the program, expands the sub- 
stitutions of its machine-code Hoare logic, examines the 
formal parameter declarations to derive function precon- 
ditions, and examines result declarations to derive post- 
conditions. A bug in the VCgen will lead to the wrong 
formula being proved and checked. 

The soundness of a PCC system’s typing rules and 
VCgen can, in principle, be proved as a metatheo- 
rem. Human-checked proofs of type systems are almost 
tractable; the appendices of Necula’s thesis [16] and Mor- 
risett et al.’s paper [14] contain such proofs, if not of the 
actual type systems used in PCC systems, then of their 
simplified abstractions. But constructing a mechanically- 
checkable correctness proof of a full VCgen would be a 
daunting task. 



Foundational PCC. Unlike type-specialized PCC, the 
foundational PCC described by Appel and Felty [3] 
avoids any commitment to a particular type system and 
avoids using a VC generator. In foundational PCC the op- 
erational semantics of the machine code is defined in a 
logic that is suitably expressive to serve as a foundation 
of mathematics. We use higher-order logic with a few ax- 
ioms of arithmetic, from which it is possible to build up 
most of modern mathematics. The operational semantics 
of machine instructions [12] and safety policies [2] are 
easily defined in higher-order logic. In foundational PCC 
the code provider must give both the executable code plus 
a proof in the foundational logic that the code satisfies 
the consumer’s safety policy. The proof must explicitly 
define, down to the foundations of mathematics, all re- 
quired concepts and explicitly prove any needed proper- 
ties of these concepts. 

Foundational PCC has two main advantages over type- 
specialized PCC — it is more flexible and more secure. 
Foundational PCC is more flexible because the code pro- 
ducer can “explain” a novel type system or safety argu- 
ment to the code consumer. It is more secure because the 
trusted base can be smaller: its trusted base consists only 
of the foundational verification system together with the 
definition of the machine instruction semantics and the 
safety policy. A verification system for higher-order logic 
can be made quite small [10, 17]. 

In our research project at Princeton University (with 
the help of many colleages elsewhere) we are building 
a foundational PCC system, so that we can specify and 
automatically prove and check the safety of machine- 
language programs. In this paper I will explain the com- 
ponents of the system. 



2 Choice of logic and framework 

To do machine-checked proofs, one must first choose 
a logic and a logical framework in which to manipulate 
the logic. The logic that we use is Church's higher-order 
logic with axioms for arithmetic; we represent our logic, 
and check proofs, in the LF metalogic [10] implemented 
in the Twelf logical framework [18]. We have chosen LF 
because it naturally produces proof objects that we can 
send to a “consumer.” 

The Twelf system allows us to specify constructors of 
our object logic. Our object logic has types tp; its prim- 
itive types are propositions o and numbers num; there is 
an arrow constructor to build function types, and pair 
to build tuples. For any object-logic type T, object-logic 
expressions of that type have metalogical type tm T. Fi- 
nally, for any formula A we can talk about proofs of A, 
which belong to the metalogical type pf (A ) . 
tp : type . 

tm : tp -> type, 

o: tp . num: tp. 

arrow: tp -> tp -> tp. 

%infix right 14 arrow, 
pair: tp -> tp -> tp . 
pf : tm o -> type. 

We have object-logic constructors lam (to construct 
functions), @ (to apply a function to an argument, written 
infix), imp (logical implication), and forall (universal 
quantification): 

lam: (tm T1 -> tm T2) -> tm (T1 arrow T2) 
@ : tm (T1 arrow T2) -> tm T1 -> tm T2 . 

%infix left 20 @. 
imp : tm o -> tm o -> tm o. 

%infix right 10 imp. 
forall : (tm T -> tm o) -> tm o. 

The trick of using 1 am and @ to coerce between met- 
alogical functions tm T1 -> tm T2 and object-logic 
functions tm (T1 arrow T2) is described by Harper, 
Honsell, and Plotkin [10]. We need object-logic functions 
so that we can quantify over them using forall; that is, 
the type of F in forall [F] predicate (F) must 
be tm T for some T such as num arrow num, but can- 
not be tm T1 -> tm T2. 

We have introduction and elimination rules for these 
constructors (rules for pairing omitted here): 
beta_e: {P: tm T -> tm o} 

pf (P (lam F 0 X) ) -> pf (P (F X) ) 
beta_i : {P: tm T -> tm o} 

pf (P (F X) ) -> pf (P (lam F @ X) ) 

imp_i : (pf A -> pf B) -> pf (A imp B) . 

imp_e : pf (A imp B) -> pf A -> pf B. 
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f orall_i : 

({X:tm T}pf(A X)) -> pf(forall A). 

f orall_e : 

pf (forall A) -> {X:tm T}pf (A X) . 

not_not_e : pf ( (B imp forall [A] A) 
imp forall [A] A) 

-> pf B. 

Our proofs don’t need extensionality or the general axiom 
of choice. 

Once we have defined the constructors of the logic, 
we can define lemmas and new operators as definitions 
in Twelf: 

and : tm o -> tm o -> tm o = 

[A] [B] 

forall [C] (A imp B imp C) imp C. 

%infix right 12 and. 

and_i : pf A -> pf B -> pf (A and B) = 
[pi : pf A] [p2 : pf B] 
forall_i [c: tm o] 

imp_i [ p 3 ] imp_e (imp_e p3 pi) p2 . 

and_el : pf (A and B) -> pf A = 

[pi : pf (A and B) ] 
imp_e (forall_e pi A) 

(imp_i [p2: pf A] imp_i [p3: pf B] p2) . 

Of course, the defined lemmas are checked by machine 
(the Twelf type checker), and need not be trusted in the 
same way that the core inference rules are. Our interactive 
tutorial [ 1 ] provides an informal introduction to our object 
logic. 



3 Specifying machine instructions 



We start by modeling a specific von Neumann ma- 
chine, such as the Sparc or the Pentium. A machine state 
comprises a register bank and a memory, each of which 
is a function from integers (addresses) to integers (con- 
tents). Every register of the instruction-set architecture 
(ISA) must be assigned a number in the register bank: the 
general registers, the floating-point registers, the condi- 
tion codes, and the program counter. Where the ISA does 
not specify a number (such as for the PC) we use an arbi- 
trary index: 
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A single step of the machine is the execution of one in- 
struction. We can specify instruction execution by giving 
a step relation (r,m) i— > ( r',m ') that describes the relation 
between the prior state ( r,m ) and the state ( r',m ') of the 
machine after execution. 

For example, to describe the instruction r\ <— r 2 + rj 
we might start by writing, 

(, r,m ) i— > ( r',m ') 

/ I r( 2) + r(3) A (Vx^ l./(x) = r(x)) Am' = m 

In fact, we can define add (i,j,k) as this predicate on 
four arguments (r, m, r' , m')\ 

add (i,j,k) = 

A ,r,m,r',m' . r' (i) = r(j) + r(k ) 

A (Vx 7 ^ i. r'(x) = r(x)) 

A m! = m 

Similarly, we can define the instruction r, <— m[rj + c] 
as 

load(t, 7 ,c) = 

Ar, m,^ ,m! . r'(i) =m(r(j) + c) 

A (Vx 7 ^ i. r'(x) = r(x)) A m! = m 

But we must also take account of instruction fetch and 
decoding. Suppose, for example, that the add instruction 
is encoded as a 32-bit word, containing a 6 -bit field with 
opcode 3 denoting add, a 5-bit field denoting the destina- 
tion register ;, and 5-bit fields denoting the source regis- 
ters j,k : 
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The load instruction might be encoded as. 
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Then we can say that some number w decodes to an 
instruction instr iff. 
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decode(w, instr) = 

(3 i,j,k. 

0<;<2 5 A 0<;<2 5 A 0<k<2 5 A 
w = 3 • 2 26 + i • 2 21 + j • 2 16 + k-2° A 
instr = add (i,j,k)) 

V (3i,;,c. 

0 < ; < 2 5 A 0 < y' < 2 5 A 0 < c < 2 16 A 
w= 12-2 26 + A2 21 + j-2 16 + c-2° A 
instr = load(;. j, sign-extend(c)j) 

V ... 

with the ellipsis denoting the many other instructions of 
the machine, which must also be specified in this formula. 

Neophytos Michael and I have shown [12] how to scale 
this idea up to the instruction set of a real machine. Real 
machines have large but semiregular instruction sets; in- 
stead of a single global disjunction, the decode relation 
can be factored into operands, addressing modes, and so 
on. Real machines don't use integer arithmetic, they use 
modular arithmetic, which can itself be specified in our 
higher-order logic. Some real machines have multiple 
program counters (e.g., Sparc) or variable-length instruc- 
tions (e.g., Pentium), and these can also be accommo- 
dated. 

Our description of the decode relation is heavily fac- 
tored by higher-order predicates (this would not be pos- 
sible without higher-order logic). We have specified the 
execution behavior of a large subset of the Sparc archi- 
tecture (without register windows or floating-point). For 
PCC, it is sufficient to specify a subset of the machine ar- 
chitecture; any unspecified instruction will be treated by 
the safety policy as illegal, which may be inconvenient for 
compilers that want to generate that instruction, but which 
cannot compromise safety. 

Our Sparc specification has two components, a “syn- 
tactic” part (the decode relation) and a semantic part (the 
definitions of add, load, etc.). The syntactic part is de- 
rived from a 151-line specification written in the SLED 
language of the New Jersey Machine-Code Toolkit [19]; 
our translator expands this to 1035 lines of higher-order 
logic, as represented in Twelf; but we believe that a more 
concise and readable translation would produce only 500- 
600 lines. The semantic part is about 600 lines of logic, 
including the definition of modular arithmetic. 

4 Specifying safety 

Our step relation ( r,m ) i— > (r 1 ,m!) is deliberately par- 
tial; some states have no successor state. In these states 



the program counter r( PC) points to an illegal instruction. 
Now we will proceed to make it even more partial, by 
defining as illegal those instructions that violate our safety 
policy. 

For example, suppose we wish to specify a safety pol- 
icy that “only readable addresses will be loaded,” where 
the predicate readable is given some suitable definion 
such as 

readable(x) 0 < x < 1000 

(see Appel and Felten [2] for descriptions of security poli- 
cies that are more interesting than this one). 

We can add a new conjunct to the semantics of the load 
instruction, 

load(i,y',c) = 

’kr,m,r J ,m! . r'{i) =m(r(j) + c) 

A readable(r(y) +c) 

A (Vx 7^ i. r'(x) =r(x)) A m' = m. 

Now, in a machine state where the program counterpoints 
to a load instruction that violates the safety policy, our 
step relation i— > does not relate this state to any succes- 
sor state (even though the real machine “knows how” to 
execute it). 

Using this partial step relation, we can define safety; a 
given state is safe if, for any state reachable in the Kleene 
closure of the step relation, there is a successor state: 

s afe- state (r,m) = 

Mr 1 ,m! . (r,m <->* r* ,m') => 3 r",m". / ,m! i-> r" ,m" 

A program is just a sequence of integers (representing 
machine instructions); we say that a program p is loaded 
at a location start in memory m if 

loaded (p,m, start) = Vi £ dom(p). m(i + start) = p(i) 

Finally (assuming that programs are written in 
position-independent code), a program is safe if, no mat- 
ter where we load it in memory, we get a safe state: 

safe(p) = 

Vr, m, start, loaded (p,m, start) A r(pc) = start =$■ 
safe-state(r.m) 

The important thing to notice about this formulation is 
that there is no verification-condition generator. The syn- 
tax and semantics of machine instructions, implicit in a 
VCgen, have been made explicit - and much more con- 
cise - in the step relation. But the Hoare logic of machine 
instructions and typing rules for function parameters, also 
implicit in a VCgen, must now be proved as lemmas - 
about which more later. 
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5 Proving safety 



trust the assembler. 



In a sufficiently expressive logic, as we all know, prov- 
ing theorems can be a great deal more difficult than 
merely stating them - and higher-order logic is certainly 
expressive. For guidance in proving safety of machine- 
language programs we should not particularly look to pre- 
vious work in formal verification of program correctness. 
Instead, we should think more of type checking: auto- 
matic proofs of decidable safety properties of programs. 

The key advances that makes it possible to generate 
proofs automatically are typed intermediate languages 
[11] and typed assembly language [14], Whereas con- 
ventional compilers type-check the source program, then 
throw away the types (using the lambda-calculus principle 
of erasure) and then transform the program through pro- 
gressively lower-level intermediate representations until 
they reach assembly language and then machine lan- 
guage, a type -preserving compiler uses typed intermedi- 
ate languages at each level. If the program type-checks 
at a low level, then it is safe, regardless of whether the 
previous (higher-level) compiler phases might be buggy 
on some inputs. As the program is analyzed into smaller 
pieces at the lower levels, the type systems become pro- 
gressively more complex, but the type theory of the 
1990’s is up to the job of engineering the type systems, 
source code 
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Conventional Compiler 

TAL was originally designed to be used in a certify- 
ing compiler, but one that certifies the assembly code and 
uses a trusted assembler to translate to machine code. But 
we can use TAL to help generate proofs in a PCC system 
that directly verifies the machine code. In such a system, 
the proofs are typically by induction, with induction hy- 
potheses such as, “whenever the program-counter reaches 
location /, the register 3 will be a pointer to a pair of in- 
tegers.” These local invariants can be generated from the 
TAL formulation of the program, but in a PCC system 
they can be checked in machine code without needing to 
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Typing rules for machine language. In important in- 
sight in the development of PCC is that one can write 
type-inference rules for machine language and machine 
states. For example, Necula [15] used rules such as 

III h X : X] X X2 
m h m(x) : Xi A m(x+ 1) : X 2 

meaning that if x has type Xi x X 2 in memory m - meaning 
that it is a pointer to a boxed pair - then the contents of 
location x will have type Xi and the contents of location 
x + 1 will have type x? . 

Proofs of safety in PCC use the local induction hy- 
potheses at each point in the program to prove that the 
program is typable. This implies, by a type -soundness ar- 
gument, that the program is therefore safe. 

If the type system is given by syntactic inference rules, 
the proof of type soundness is typically done by syntac- 
tic subject reduction - one proves that each step of com- 
putation preserves typability and that typable states are 
safe. The proof involves structural induction over typing 
derivations. In conventional PCC, this proof is done in the 
metatheory, by humans. 

In foundational PCC we wish to include the type- 
soundness proof inside the proof that is transmitted to 
the code consumer because (1) it’s more secure to avoid 
reliance on human-checked proofs and (2) that way we 
avoid restricting the protocol to a single type system. But 
in order to do a foundational subject-reduction theorem, 
we would need to build up the mathematical machinery to 
manipulate typing derivations as syntactic objects, all rep- 
resented inside our logic using foundational mathematical 
concepts - sets, pairs, and functions. We would need to 
do case analyses over the different ways that a given type 
judgement might be derived. While this can all be done, 
we take a different approach to proving that typability im- 
plies safety. 

We take a semantic approach. In a semantic proof one 
assigns a meaning (a semantic truth value) to type judge- 
ments. One then proves that if a type judgement is true 
then the typed machine state is safe. One further proves 
that the type inference rules are sound, i.e., if the premises 
are true then the conclusion is true. This ensures that 
derivable type judgements are true and hence typable ma- 
chine states are safe. 

The semantic approach avoids formalizing syntactic 
type expressions. Instead, one formalizes a type as a set 
of semantic values. One defines the operator x as a func- 
tion taking two sets as arguments and returning a set. The 
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above type inference rule for pair projection can then be 
replaced by the following semantic lemma in the founda- 
tional proof: 

bv : m Ti x T 2 

f -m(x) : m Xi A m(x+ 1) X 2 

Although the two forms of the application type- 
inference rule look very similar they are actually signif- 
icantly different. In the second rule Xj and X 2 range over 
semantic sets rather than type expressions. The relation 
b in the second version is defined directly in terms of a 
semantics for assertions of the form x X. The second 
“rule” is actually a lemma to be proved while the first rule 
is simply a part of the definition of the syntactic relation 
b. For the purposes of foundational PCC, we view the se- 
mantic proofs as preferable to syntactic subject-reduction 
proofs because they lead to shorter and more manageable 
foundational proofs. The semantic approach avoids the 
need for any formalization of type expressions and avoids 
the formalization of proofs or derivations of type judge- 
ments involving type expressions. 

5.1 Semantic models of types 



Building semantic models for type systems is inter- 
esting and nontrivial. In a first attempt, Amy Felty and 
I [3] were able to model a pure-functional (immutable 
datatypes) call-by-value language with records, address 
arithmetic, polymorphism and abstract types, union and 
intersection types, continuations and function pointers, 
and covariant recursive types. 

Our simplest semantics is set-theoretic: a type is a set 
of values. But what is a value? It is not a syntactic con- 
struct, as in lambda-calculus; on a von Neumann machine 
we wish to use a more natural representation of values that 
corresponds to the way procedures and data structures are 
represented in practice. This way, our type theory can 
match reality without a layer of simulation in between. 
We can represent a value as a pair (m,x), where m is a 
memory and x is an integer (typically representing an ad- 
dress). 

To represent a pointer data structure that occupies a 
certain portion of the machine’s memory, we let x be the 
root address of that structure. For example, the boxed pair 
of integers (5,7) represented at address 108 would be rep- 
resented as the value ({108 1 — > 5, 109 1 — 7 } , 108). 
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m 



108 
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7 



To represent a function value, we let x be the entry ad- 
dress of the function; here is the function f(x) = x+ 1, 
assuming that arguments and return results are passed in 
register 1 : 



x 

200 




m 

1111 

4070 



r, := ri +l 
jump(r 1 ) 



This model of values would be sufficient in a semantics 
of statically allocated data structures, but to have dynamic 
heap allocation we must be able to indicate the set a of 
allocated addresses, such that any modification of mem- 
ory outside the allocated set will not disturb already al- 
located values. A state is a pair (a. in), and a value is a 
pair ((a,m),x) of state and root-pointer. The allocset a 
is virtual: it is not directly represented at run time, but is 
existentially quantified. 



Limitations. In the resulting semantics [3] we could 
model heap allocation, but we could not model mutable 
record-fields; and though our type system could describe 

datatype 'a list = nil 



I : : of ' a * ' a list 

we could not handle recursions where the type being de- 
fined occurs in a negative (contravariant) position, as in 

datatype exp = APP of exp * exp 
LAM of 



exp 



exp 



where the boxed occurrence of exp is a negative occur- 
rence. Contravariant recursion is occasionally useful in 
ML, but it is the very essence of object-oriented program- 
ming, so these limitations (no mutable fields, no con- 
travariant recursion) are quite restrictive. 



5.2 Indexed model of recursive types 



In more recent work, David McAllester and I have 
shown how to make an “indexed” semantic model that can 
describe contravariant recursive types [4]. Instead of say- 
ing that a type is a set of values, we say that it is a set of 
pairs (k. v) where k is an approximation index and visa 
value. The judgement (k.v) £ x means, “v approximately 
has type x, and any program that runs for fewer than k in- 
structions can’t tell the difference.” The indices k allow 
the construction of a well founded recursion, even when 
modeling contravariant recursive types. 

The type system works both for von Neumann ma- 
chines and for A-calculus; here I will illustrate the latter. 
We define a type as a set of pairs (k. v) where k is a non- 
negative integer and v is a value and where the set x is 
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such that if (k.v) £ x and 0 < j < k then (j,v) £ X. For 
any closed expression e and type x we write e : k x if e is 
safe for k steps and if whenever e i— v for some value v 
with j < k we have (k — j, v) £ x; that is, 

e : k X = V/Ve'. 0 < j < k A e i— ^ e' A nf(e') => 
{k~ j,e') £ X 

where nf(e') means that e' is a normal form — has no suc- 
cessor in the call-by-value small-step evaluation relation. 

We start with definitions for the sets that represent the 
types: 

J- = U 

T = {(k,v) | ^> 0} 

int = {(fc,0) , {k,l ) , . . . | k > 0} 
xixx 2 = {(fc,(vi,v 2 )) I V7 < k. (j,v\) e Xi A (y,v 2 > € x 2 } 

o — > x = {(fc,Axe) | Mj <kMv. (j,v) £ a => e[v/x] :j x} 

pF ={MI (k,v>eF*+ 1 (-L)} 

Next we define what is meant by a typing judgement. 
Given a mapping F from variables to types, we write 
r (=a e : a to mean that 

Vo.o : k T => a(e) : k a 

where a(e) is the result of replacing the free variables in e 
with their values under substitution o. To drop the index 
k, we define 

r|=e : a = \/k.F\= k e cl 

Soundness theorem: It is trivial to prove from these 

definitions that if he : a and e 1 — >* e' then e' is not 
stuck, that is, e' 1 — > e" . 

Well founded type constructors. We define the notion 
of a well founded type constructor. Here I will not give 
the formal definition, but state the informal property that 
if F is well founded and x : F(x), then to extract from x 
a value of type x, or to apply x to a value of type x, must 
take at least one execution step. The constructors x and 
— are well founded. 

Typing rules. Proofs of theorems such as the following 
are not too lengthy: 

rhtti(e) : Xi rhJt2(e):x 2 rhe : Xi xx 2 
The : Xi x x 2 rhJti(e):xi 

ThcGOt — F\=e2-CL 

rheie 2 : P 



Finally, for any well founded type-constructor F, we have 
equirecursive types: /jF = F(/jF). 

Our paper [4] proves all these theorems and shows the 
extension of the result to types and values on von Neu- 
mann machines. 

5.3 Mutable fields 

Our work on mutable fields is still in a preliminary 
stage. Amal Ahmed, Roberto Virga, and I are investigat- 
ing the following idea. Our semantics of immutable fields 
viewed a “state” as a pair (a,m) of a memory m and a set 
a of allocated addresses. To allow for the update of ex- 
isting values, we enhance a to become a finite map from 
locations to types. The type a(l) at some location l speci- 
fies what kinds of updates at that location will preserve all 
existing typing judgements. Then, as before, a type is a 
predicate on states (a.ni) and root-pointers x of type inte- 
ger. In our object logic, we would write the types of these 
logical objects as, 

77 fi 11 

allocset = num — > type 

value = allocset X memory X num 
type = num X value — > o 

The astute reader will notice that the metalogical type of 
“type” is recursive, and in a way that has an inconsistent 
cardinality: the set of types must be bigger than itself. 
This problem had us stumped for over a year, but we now 
have a tentative solution that replaces the type (in the al- 
locset) with the Godel number of a type. We hope to re- 
port on this result soon; we are delayed by our general 
practice of machine-checking our proofs in Twelf before 
submitting papers for publication, which in this case has 
saved us from some embarrassment. 

5.4 Typed machine language 

Morrisett’s typed assembly language [14] is at too high 
a level to do proof-carrying code directly. Kedar Swadi, 
Gang Tan, Roberto Virga, and I have been designing 
a lower-level representation, called typed machine lan- 
guage, that will serve as the interface between compilers 
and our prover. In fact, we hope that a clean enough def- 
inition of this language will shift most of the work from 
the prover to the compiler’s type-checker. 

In order to avoid overspecializing the typed machine 
language (TML) with language-specific constructs such 
as records and disjoint-union variants, our TML will use 
very low-level typing primitives such as union types, in- 
tersection types, offset (address-arithmetic) types, and de- 
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pendent types. This will make type-checking of TML dif- 
ficult; we will need to assume that each compiler will have 
a source language with a decidable type system, and that 
translation of terms (and types) will yield a witness to the 
type-checking of the resultant TML representation. 

Abstract machine instructions. One can view ma- 
chine instructions at many levels of abstraction: 

1. At the lowest level, an instruction is just an integer, 
an opcode encoding. 



Hoare logic. In reasoning about machine instructions at 
a higher level of abstraction, notions from Hoare logic 
are useful: preconditions, postconditions, and substition. 
Without adding any new axioms, we can define a notion 
of predicates on states to serve as preconditions and post- 
conditions, and substitution as a relation on predicates. 
But this can rapidly become inefficient, leading to proofs 
that are quadratic or exponential in size. Kedar Swadi, 
Roberto Virga, and I have taken some steps in lemma- 
tizing substitution so that proofs don’t blow up [5]; in- 
teresting related work has been done in Compaq SRC’s 
extended static checker [9] . 



2. At the next level, it implements a relation on raw ma- 
chine states (r,m) i— » {/ ,m'). 

3. At a higher level, we can say that the Sparc add in- 
struction implements a machine-independent notion 
of add , and similarly for other instruction. 

4. Then we can view add as manipulating not just regis- 
ters, but local variables (which may be implemented 
in registers or in the activation record). 

5. We can view this instruction as one of various typed 
instructions on typed values; in the usual view, add 
has type int x int — > int, but the address-arithmetic 
add has type 

(to X T] x ... x x„) x const(i) — > (x,- x Xj+l x . . . x x„) 

for any i. x 
108 

x+2 

110 



m 



y 0 


fc o 


>’i 


fc i 




fc 2 


Jb 


fc 3 



6. Finally, we can specialize this typed add to the par- 
ticular context where some instance of it appears, for 
example by instantiating the i, n, and x, in the previ- 
ous example. 

Abstraction level 1 is used in the statement of the theorem 
(safety of a machine-language program p). Abstraction 
level 5 is implicitly used in conventional proof-carrying 
code [15]. Our ongoing research involves finding seman- 
tic models for each of these levels, and then proving lem- 
mas that can convert between assertions at the different 
levels. 



Software engineering practices. We define all of these 
abstraction levels in order to modularize our proofs. Since 
our approach to PCC shifts most of the work to the hu- 
man prover of static, machine-checkable lemmas about 
the programming language’s type system, we find it im- 
perative to use the same software engineering practices in 
implementing proofs as are used in building any large sys- 
tem. The three most important practices are (1) abstrac- 
tion and modularity, (2) abstraction and modularity, and 
(3) abstraction and modularity. At present, we have about 
thirty thousand lines of machine-checked proofs, and we 
would not be able to build and maintain the proofs without 
a well designed modularization. 



6 Pruning the runtime system 

Just as bugs in the compiler (of a conventional system) 
or the proof checker (of a PCC system) can create security 
holes, so can bugs in the runtime system: the garbage col- 
lector, debugger, marshaller/unmarshaller, and other com- 
ponents. An important part of research in Foundational 
PCC is to move components from the runtime system to 
the type-checkable user code. Then, any bugs in such 
components will either be detected by type-checking (or 
proof-checking), or will be type-safe bugs that may cause 
incorrect behavior but not insecure behavior. 

Garbage collectors do two strange things that have 
made them difficult to express in a type-safe language: 
they allocate and deallocate arenas of memory contain- 
ing many objects of different types, and they traverse (and 
copy) objects of arbitrary user-chosen types. Daniel Wang 
has developed a solution to these problems [22], based on 
the motto, 

Garbage collection = Regions + Intensional types. 
That is, the region calculus of Tofte and Talpin [20] can 
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be applied to the problem of garbage collection, as no- 
ticed in important recent work by Walker, Crary, and Mor- 
risett [21]; to traverse objects of unknown type, the inten- 
sional type calculi of originally developed by Harper and 
Morrisett [11] can be applied. Wang’s work covers the 
region operators and management of pointer sharing; re- 
lated work by Monnier, Saha, and Shao [13] covers the 
intensional type system. 

Other potentially unsafe parts of the runtime system 
are ad hoc implementations of polytypic functions - those 
that work by induction over the structure of data types 
- such as polymorphic equality testers, debuggers, and 
marshallers (a.k.a. serializers or picklers). Juan Chen and 
I have developed an implementation of polytypic primi- 
tives as a transformation on the typed intermediate repre- 
sentation in the SML/NJ compiler [6]. Like the Xr trans- 
formation of Crary and Weirich [8] it allows these poly- 
typic functions to be typechecked, but unlike their calcu- 
lus, ours does not require dependent types in the typed 
intermediate language and is thus simpler to implement. 



7 Conclusion 

Our goal is to reduce the size of the trusted comput- 
ing base of systems that run machine code from untrusted 
sources. This is an engineering challenge that requires 
work on many fronts. We are fortunate that during the 
last two decades, many talented scientists have built the 
mathematical infrastructure we need - the theory and im- 
plementation of logical frameworks and automated theo- 
rem provers, type theory and type systems, compilation 
and memory management, and programming language 
design. The time is ripe to apply all of these advances 
as engineering tools in the construction of safe systems. 
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